Systems and/or methods for identifying service candidates based on service identification indicators and associated algorithms

ABSTRACT

Certain example embodiments relate to algorithmic and/or programmatic approaches to identifying service candidates from among business process functions. In certain example embodiments, a method of analyzing functions of a business process model for possible exposure as service capabilities in a service-oriented business process system (SO-BPS) is provided. A business process model defined by a plurality of objects is received, with each said object having metadata attributes associated therewith. Business process analysis intelligence is obtained at design time for each said object. Process performance intelligence at run time is obtained for each said object. Indicators corresponding to the design time and run time gathered intelligence are stored together with the metadata attributes for the corresponding object. Via at least one processor of the SO-BPS, an overall service candidate algorithm is applied to the stored indicators to arrive at a total service eligibility value for each process function in the model.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/149,003filed May 31, 2011, now allowed, the entire contents of each of whichare hereby incorporated by reference in this application.

FIELD OF THE INVENTION

Certain example embodiments described herein relate to algorithmicand/or programmatic approaches to identifying service candidates fromamong business process functions. In certain example embodiments, thereare provided techniques for gathering indicators based on design timebusiness process analysis intelligence and run time process performanceintelligence, storing such indicators together with metadata attributesfor each model object, performing service candidate analysis, and/orresponding to service requests.

BACKGROUND AND SUMMARY OF EXAMPLE EMBODIMENTS OF THE INVENTION

A business process is a series of enterprise tasks, often undertaken forthe purpose of creating valuable output for an internal or externalcustomer. For instance, a business process may give organizationalactions structure across time, place, and functions. Business processeshave become a chosen means to describe, analyze, execute, and controloperational structures across departments, business units, and evenbusiness partners.

Business process management (BPM) aims at their improvement for the sakeof overall business success. Amongst others, software-enabled businessprocess automation is an instrument to increase process efficiencies andeffectiveness. Business process models have been established to specifyprocesses throughout BPM projects. For automation purposes, for example,they document and structure process information prior to theirtransformation into executable (e.g., code-based) specifications.Modeling and transformation oftentimes are prerequisites for soundprocess automation.

Business process models help describe the logical and timely flow ofbusiness processes as a map. They may help visualize process activitiesas graphical symbols, possibly connecting them to a linear or otherorder. Logical operators may indicate when the flow splits intoalternative or parallel paths, when they merge again into one, etc. Thisso-called control flow is a part of a business process model. Thecontrol flow may be complemented by additional model elements thatdiffer depending on the perspective. A conceptual-organizationalperspective targets the organizational process context including, forexample, intra- and inter-organizational division of labor, interactionbetween human activities, their technical support, product outcome, etc.

The modeling language EPC (event-driven process chain) has prevailed asa de-facto standard for such conceptual business processes. Itcomplements process activities by organizational resources responsible,input required, and output produced, supporting software applicationsystems, organizational objectives, risks, etc. While being rather easyto use even by non-technical process analysts, it also includesimportant information on the logical flow, which makes it a semi-formalrequirements basis for technical process implementation. It is at thetransformation from conceptual into technical business process modelswhere business process modeling changes the perspective fromorganizational design into technical engineering.

Model-driven process automation passes the control flow described in aconceptual business process model on to a technical business processmodel. Here, it is complemented by technical information such as, forexample, process variables for storing process information duringexecution, online forms for user interaction, exceptions and theirhandling, communication patterns (asynchronous/synchronous), consistentdata exchange, etc. To make a process executable, process activitiestypically are assigned to automated software functionality or tosemi-automated user interfaces. Depending on the chosen modelinglanguage and the targeted deployment system, this transformation mayresult in a second graphical diagram (e.g., in BPMN 2.0), directly intoa code-based script (e.g., XPDL, BPEL, or the like), etc.

The resulting technical process models are to be deployed into theprocess engine of a business process management system (BPMS) orworkflow management system (WFMS), which allows for starting, executingand tracking instances of this process efficiently.

The idea of using business processes as blueprint for cross-applicationsoftware systems is as old as the concept of workflow management systems(WFMS) and enterprise application integration (EAI). One factor makingbusiness process automation a real technical challenge, though, is theplethora of heterogeneous and increasingly distributed software systemsto be integrated and connected along a given process flow.

Most recently, service-oriented architectures (SOA) has attempted tomeet this integration challenge by exposing and integrating remotesoftware functionality through well-defined software service interfaces.Early proponents conceived of SOA instead as a specific style ofdistributed software architectures based on the so-calledfind-bind-execute relationship between service providers and consumers.More recent notions advance this integration view towards the potentialSOA offers for business process automation. They put process automationinto the center of the SOA discussion. The capability to composeservices loosely opens new avenues to implementing business processesflexibly following dynamic business requirements. The adoption ofstandardized service interfaces allows for the reusing of services indifferent business processes, as well as flexibly replacing servicesaccording to evolving business requirements. In this sense, SOA has beenconsidered a paradigm for organizing and utilizing distributedcapabilities that may be under the control of different ownershipdomains.

Web services represent one of the most recent incarnations ofservice-oriented software technologies. Unlike previous servicetechnologies, web services leverage and further protocol and datastandards.

Scientific discourse and best practices of service-orientedarchitectures provide a number of service-oriented design principles.While the SOA approach reinforces well-established, general softwarearchitecture principles of interface-orientation, interoperability,autonomy, and modularity, it also adds additional themes ofprocess-orientation.

Thus, service-oriented design seeks to improve business processflexibility by the separation of process structure (e.g., process flow)and process institutionalization (e.g., selection of servicecapabilities conducting process activities). Business process systemsbenefit from service-orientation in several aspects. First, processstructure is revisited to prepare for well-defined, comprehensivefunctional interfaces allowing plug-and-play services to form newbusiness processes. Second, IT support and technical infrastructure, aswell as personnel assignment, are addressed by considering processinstitutionalization alternatives. They affect cost-effectiveness asmuch as load balancing and performance figures. Third, aspects of dataredundancy and data integration are of interest for service-orientedbusiness process systems (SO-BPS), since cross-organizational serviceprovision risks to increasing data redundancy and data control.

Service identification, which involves locating process activities thatappear worthwhile being exposed as service, is considered a part ofservice-oriented system engineering and is at the crossroad betweenconceptual and technical business process models. Furthermore, serviceidentification typically is one of the first conceptual activities to beconducted in an SO-BPS project. Quality of identified service candidateshelps determine overall system quality to a large extent. Flaws in thisactivity can propagate to all later activities, potentially causingcost-intensive iterations. Because of the potentially high impact ofservice identification, systematic and thorough techniques aredesirable. Potential service functionality can be searched for indifferent contexts. While the business context sets the structural andbehavioral service requirements, the IT context represents existingsoftware systems as possible service providers. However, as the latterrefers to an IT inventory analysis, it risks ignoring real businessneeds. Therefore, service identification in this case is considered astransforming business process requirements into well-defined servicerequirements.

It is noted that a majority of current service-oriented developmentmodels take business process models into account. However, it isbelieved by the inventor of the instant application that none of thesecurrent approaches specifies which prerequisites must be met by businessprocess models to be a suitable basis for service-oriented systemdesign. Indeed, they must meet some minimum design standards to be auseable blueprint for service identification as a prerequisite forservice composition and process automation.

Therefore, service identification remains a purely manual consultingservice missing any systematic and quantitative support. Serviceidentification has been addressed as a major activity of variousacademic service-oriented development models, but it hardly has beentaken on by SOA governance software. Even so, they are mostly vagueguidelines that apparently lack any metric to evaluate servicecandidates quantitatively. Some service identification approaches misstaking process or business structures into account by only technicallyanalyzing software landscapes for service exposure. The existing fewapproaches that identify service eligibility of a process function inenterprise models are limited to one service design principle (e.g.,data cohesion) and do not leverage contextual information stored inextensive business process architecture models. Thus, it is believed bythe inventor of the instant application that none of the existing toolsand methods available provides an automatic mechanism (e.g., analgorithm) to identify service candidates among business processfunctions.

Thus, it will be appreciated by those skilled in the art that there is aneed in the art for techniques that provide an algorithmic and/orprogrammatic approach to identifying service candidates from amongbusiness process functions.

One aspect of certain example embodiments of this invention relates tousing conceptual business process models as a comprehensive and valuableinformation basis for service identification.

An aspect of certain example embodiments of this invention relates to analgorithmic and/or programmatic approach to identifying servicecandidates from among business process functions.

Another aspect of certain example embodiments relates to evaluating aprocess step as a service candidate.

Another aspect of certain example embodiments relates to providinggovernance support for service planning governance process, while alsolinking to business process models and incorporating business-orientedmodeling.

Another aspect of certain example embodiments relates to analysisfeatures that support domain composition (which describes servicerequirements from business processes) for service identification.

Another aspect of certain example embodiments relates to an algorithmicand/or programmatic tool for business process-driven serviceidentification.

Still another aspect of certain example embodiments relates to theflagging of indicators for reusability.

Still another aspect of certain example embodiments relates to identifyservice candidates having a richness in business semantics provided byevent-driven process chains.

Yet another aspect of certain example embodiments relates togoal-service modeling (GSM) as a second activity complementing top-downprocess decomposition and bottom-up asset analysis.

Yet another aspect of certain example embodiments relates to determiningor calculating indicators including, for instance, process indicators,data indicators, organizational indicators, and goal and eventindicators.

Yet another aspect of certain example embodiments relates torepresenting determined or calculated indicators in a ServiceIdentification and Evaluation Matrix (SIEM).

Yet another aspect of certain example embodiments relates to applying aformula to weight determined or calculated indicators to arrive at ascore indicative of the total service eligibility.

Yet another aspect of certain example embodiments relates to comparingtotal service eligibility scores to a threshold, e.g., to filter outfunctions that do not qualify as candidates for service eligibility.

In certain example embodiments, a method of analyzing functions of abusiness process model for possible exposure as service capabilities ina service-oriented business process system is provided. A businessprocess model defined by a plurality of objects is received, with eachsaid object having metadata attributes associated therewith. Businessprocess analysis intelligence is obtained at design time for each saidobject. Process performance intelligence at run time is obtained foreach said object. Indicators corresponding to the design time and runtime gathered intelligence are stored together with the metadataattributes for the corresponding object. Via at least one processor ofthe service-oriented business process system, an overall servicecandidate algorithm is applied to the stored indicators to arrive at atotal service eligibility value for each process function in the model.

According to certain example embodiments, a request for a servicecandidate may be responded to by recommending at least one processfunction having a sufficiently high total service eligibility value.

According to certain example embodiments, the indicators include orconsist of process indicators, data indicators, organizationalindicators, and goal and event indicators. According to certain otherexample embodiments, the indicators include or consist of at least onereusability indicator for functions in the model, at least one datacoupling indicator for functions in the model, at least one datacohesion indicator for functions in the model, at least one stakeholderintegration indicator for functions in the model, at least oneorganizational involvement indicator for functions in the model, atleast one goal-oriented indicator for service eligibility, and/or atleast one event-oriented indicator for service relevance. The totalservice eligibility value may be a weighted combination of theindicators, and the weights may correspond to one or more objectives tobe reached with the resulting service-oriented business process systemin accordance with certain example embodiments. As one example, theoverall service candidate algorithm comprises, for each said function,obtaining a first value by adding together the expected reusability ofthe function over a predefined time period, the data cohesion of thefunction, out-tasking and visibility variables respectively indicatingthe extent to which execution of the function can be out-tasked tostakeholders and can be made visible to stakeholders, obtaining a secondvalue by subtracting from the first value a degree of data coupling forthe function, a maximum number of organizational units involved in thefunction, and a maximum number of application systems involved in thefunction, and multiplying the second value by a business relevanceindicator for the function to obtain the total service eligibility valuefor the function. According to certain example embodiments, a functionmay be exposed as a service capability if the total service eligibilityvalue for the function exceeds a predetermined threshold value.

According to certain example embodiments, the design time intelligencemay be gathered by executable program logic such as, for example,scripted macros or reports, and/or the run time intelligence may begathered via an interface to a process monitoring tool or otherexecutable program logic.

According to certain example embodiments, the total service eligibilityvalues for the process functions may be ranked. For instance, the rankedtotal service eligibility values may be organized into and/or displayedin groups based on the rankings. In certain instances, the groups may beformed so as to approximate a normal distribution.

In certain example embodiments, a method of defining or refining abusiness process model is provided. A representation of at least aportion of the business process model is graphically displayed on adisplay of a computer system, with the portion including a plurality ofobjects. A user is able to select an object of the model via a userinterface. In response to a user request received via the userinterface, metadata attributes of the selected object are displayed onthe display of the computer system. Indicators corresponding to gatheredbusiness process analysis intelligence and/or gathered processperformance intelligence are displayed together with the metadataattributes in a matrix format. A total service eligibility value iscalculated via at least one processor for each process function in themodel based on a weighted summation of the indicators. The indicatorscorresponding to the business process analysis intelligence are gatheredat design time via scripted macros or reports and the indicatorscorresponding to the indicators corresponding to the process performanceintelligence are gathered at run time via an interface to a processmonitoring tool.

According to certain example embodiments, a request for a service may bereceived from the user, and/or at least one service candidate may bedisplayed to the user as a result of the request. This may in certaininstances involve plurality of service candidates are displayed. Theservice candidates may, for example, be ordered based on theirrespective total service eligibility values. In some cases, each saidservice candidate is displayed only if it exceeds a predeterminedthreshold value. In other example instances, exactly one servicecandidate is displayed, with the one displayed service candidatecorresponding to the function having the highest total serviceeligibility value.

Non-transitory computer readable storage mediums tangibly storinginstructions for performing the above-summarized and/or other methodsalso are provided by certain example embodiments.

Analogous systems also may be provided in by certain exampleembodiments. For instance, certain example embodiments relate to aservice-oriented business process system for analyzing functions of abusiness process model for possible exposure as service capabilities. Anon-transitory computer readable storage medium includes arepresentation of the business process model, with the business processmodel being defined by a plurality of objects. Each said object hasmetadata attributes associated therewith, and the metadata attributesalso are stored in the computer readable storage medium. A firstcomputer-executable intelligence gathering module is configured toobtain business process analysis intelligence at design time for eachsaid object. A second computer-executable intelligence gathering moduleis configured to obtain process performance intelligence at run time foreach said object. A computer-executable analysis module is configured to(a) receive indicators corresponding to the design time and run timegathered intelligence, and (b) apply a service candidate algorithm onsome or all of the indicators to arrive at a total service eligibilityvalue for each process function in the model. The modules are executablevia at least one processor of the system.

These aspects and example embodiments may be used separately and/orapplied in various combinations to achieve yet further embodiments ofthis invention.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages may be better and morecompletely understood by reference to the following detailed descriptionof exemplary illustrative embodiments in conjunction with the drawings,of which:

FIG. 1 is an illustrative Service Identification and Evaluation Matrixin accordance with certain embodiments;

FIG. 2 illustrates the example learning management process hierarchy inthree levels of detail;

FIG. 3 illustrates a sample process of competency planning anddevelopment for the FIG. 2 example;

FIGS. 4A-4D illustrate the sample learning management process fromend-to-end and provides detailed views on two sample leaf level EPCdiagrams;

FIG. 5 shows the results of the sample service eligibility analysis,including the overall distribution and average values;

FIG. 6 is a high-level overview of the technical structure of certainexample embodiments;

FIG. 7 is an example screenshot showing how gathered service indicatorsmay be maintained in metadata attributes in accordance with certainexample embodiments;

FIG. 8 is an example screenshot demonstrating how a new service requestmay be initiated in accordance with certain example embodiments; and

FIG. 9 is a more detailed diagram illustrating the technical approach ofcertain example embodiments at both design time and at run time.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION

Certain example embodiments involve multi-perspective eligibilityindicators, functional granularity identification, process-orientedreusability identification, data-oriented autonomy identification,organization/stakeholder oriented identification, goal-orientedidentification of business relevance, event-driven identification ofbusiness services, consolidation of service eligibility, and/or businessservice specification.

It may be desirable to analyze multi-perspective eligibility indicatorsin certain example embodiments. For example, acknowledging the value ofbusiness-orientation for service design, the SO-BPS methodology maystart with a top-down business service identification based on thelowest level of the business process hierarchy that provides businessprocess models.

Because process improvements (e.g., reducing existing processinefficiencies) are one driver for the adoption of service-orientation,many SO-BPS projects would be business process optimization projects.However, it may not be desirable to always deploy the entire spectrum ofclassical business process improvement techniques in all such endeavors.Therefore, the question of “as-is” versus “to-be” models is bypassed incertain example embodiments through the provision of a clearrecommendation to use a business process hierarchy that documents thecurrent status of current operations in sufficient detail (e.g.,complying with modeling conventions), while assuming that businessprocesses are structurally efficient (e.g., there are no bottlenecks,sequential instead of parallel processing, etc.). Hence, the bases forbusiness service identification may be thought of as detailed, as-isbusiness process models featuring high-quality operations.

One guidepost for high-quality service design implies that (elementary)services encapsulate organizational units, legal constraints, masterdata from update data, products, and markets, as well as differentvertical integration levels. This notion argues in favor of amulti-perspective analysis of business process models to reap superior(or at least improved) service candidates. Correspondingly, theguidelines may be structured along the SO-BPS views, e.g., as introducedand elaborated on below.

Thus, it may be desirable to implement functional granularityidentification in certain example embodiments. Being one SOA designprinciple, abstraction and business process orientation often istranslated into coarse, business-oriented granularity that meets variousdemands. However, excessively coarse granularity impedes generalreusability of services which is another vital design objective. Thetradeoff between fine-grained and coarse-grained services has beenaddressed by many but has not yet resolved. The advantages of smallservices are their variability and reusability promoting more adaptablesystems. However, this flexibility comes with a price in the form ofcomplexity caused by a large number of services that is difficult tomanage.

Coarse grained services, however, allow only for a few purpose-build usecases that fit only in a specific situation. Once the initial situationchanges, new services may need to be implemented, very often providingredundant functionality. Overall, identifying the right degree ofgranularity is an intricate task in SO-BPS design, and it is unlikelythat there is a single correct size for all services. Business processdecomposition has yielded the most fine granular, yet business relevantfunctions. Thus, both design criteria catering towards demandorientation (e.g., abstraction and business process orientation) havebeen addressed. It would be desirable to address principles of processautonomy and modularity before the final tailoring of functions toservice candidates is achieved. Catering towards the autonomy principlesof high cohesion and loose coupling, clustering techniques known fromsocial network analysis or component-based software design may beapplied to business process models. It is possible to cluster businessprocess functions by deleting edges with the highest “betweenness”, orthe number of shortest paths between pairs of vertices (businessactivity, IT systems, etc.) that run along it. The resulting clustersmay include functions that are good service operation candidates forminga service.

In certain instances, it may be desirable to take into accountprocess-oriented reusability, e.g., when service identification withinan SO-BPS concerns many or all business processes. To identifyreusability of functions respective service capabilities, theinter-process dependencies of functions across a given set of numerousprocess models may be analyzed. The number of occurrences of the samefunction over several business processes may help to indicate itsreusability in different business contexts. A prerequisite for thisanalysis may be that identical functions carry identical names so thatsemantically equal functions can be identified by comparing theirlabels. Two identical functions share the same input and output data. Aslong as identical data objects carry identical names, comparing inputand output data is another way to check for identical functions. Processmodeling environments, such as the ARIS business architect, for example,support multiple occurrences of the same function object. Thus,identical activities may not need to be located and counted manually.

The reusability of functions may be approximated by the furtherassessment of the function's frequency over the course of time (e.g.,during run-time). Therefore, a history of process instances may bedesirable. This is most feasible with any type of software supportlogging process performance and analyzing process instances. However,knowledge-intensive business processes characterized by manualactivities and self-organization are unlikely to be monitoredconsistently. Interviews with knowledge workers eliciting their typicalwork behavior may provide the necessitated data. The number ofnon-identical events triggering a function across all occurrences bringsanother quality to the assessment, since diverse triggering eventsindicate an even higher reusability of a function. Similarly, multipleuse of a function by different organizational or application resourcesalso demonstrates its reusability. The following example statementsdefine example indicators of functional reusability and sums them up toan overall reusability indicator:

Occ(F_(i))=number of occurrences of function i across all process modelsOrgRe(F_(i))=number of non-identical organizational units providingfunction i across all occurrencesAppRe(F_(i))=number of non-identical application systems supportingfunction i across all occurrencesInvoc(F_(i), t)=number of invocations of function i over the course oftime t

Reuse(F _(i) ,t)=Occ(F _(i))+Invoc(F _(i) ,t)+OrgRe(F _(i))+AppRe(F_(i))

F_(i): Function i

Reuse(F_(i), t): Expected reusability of function i over the course oftime t Service criteria of cohesion and coupling do not only concernfunctional aspects, but also aspects of data exchange and complexity ofexchanged data objects. One approach may be to measure the degree ofcoupling of functions by assessing its data exchange behavior. The fewerfunctions use the same data objects and the less complex shared dataobjects are, the looser the coupling of functions tend to be. Thecomplexity of shared data objects may be determined by the number ofmutual relationships as modeled in a data model. As a side effect, lowcomplexity of input/output data relates to lower data volumes, as it isrequired for improved overall performance. The following examplestatements define example indicators of functional data coupling:

DataCoupling(F_(i)) = S_(ia) + ∑C(S_(ij)) S_(ij) = D_(i)⋂D_(j)$S_{i} = {\bigcup\limits_{j}S_{ij}}$

Fi: Function i

Di: Set of data objects used by function iDa: Set of all data objects in useC(S_(ij))εN: Degree of data complexity, or number of relationshipsbetween data objections of the set S_(ij)DataCoupling(F_(i))εN: Degree of data coupling of function i

A further indication about the autonomy of a function is given by thecohesion of the data objects used by the function. One can derive thisfigure of cohesion based on the number of mutual relationships betweendata objects. The underlying assumption is that a function can beconsidered cohesive if its data objects have few relationships with eachother. Normalizing the number of relationships by subtraction from thenumber of data objects delivers a value that indicates the degree ofcohesion. The following example statements define the indicators offunctional data coupling:

DataCohesion(F _(i))=N _(i) −K _(i)

K _(i) =C(D _(i))

N _(i) =|D _(i)|

D _(i)=ID_(i)∪OD_(i)

|D_(i)|εN: Number of data objects used by function iID_(i): Set of input data of function iOD_(i): Set of output data of function iD_(i): Set of data objects used by function iDataCohesion(F_(i)): Data cohesion of function i

The number of data objects a function operates on may be an additionalindicator for service eligibility. In certain instances, it may be onlyone input and one output data object. This constraint corresponds to thecriterion that service granularity be sufficiently fine to describe allprocessing steps on business objects. On top of that, master dataobjects and inventory data objects may be processed by differentservices. Interface-orientation further asks for the unambiguousdefinition of input and output parameters. Thus, as a general rule, dataobjects may be specified by underlying data models.

Distribution of service-oriented systems refers, among other things, todifferent organizational and technical resources providing, brokering,or consuming services. Organizational units assuming one of these threeroles may be thought of as being stakeholders. Whereas existingservice-oriented procedure models tend to neglect differentstakeholders' perspectives, an organizational service identificationapproach focuses on a stakeholder's perspective. Exploiting servicemarketing research on customer integration, the “line of interaction”and the “line of visibility” may be applied as a theoretical foundationof the criteria proposed for service identification. Following thisargumentation, criteria for service eligibility of a function arewhether it can be taken over by stakeholders (shifting the line ofinteraction towards the stakeholder) or whether (parts of) it can ormust be made visible to the stakeholder. Thus, the “out-tasking” and“visibility” criteria assess the extent to which execution of thefunction can be out-tasked to stakeholders or at least made visible tothem. Whereas technical service design criteria typically are onlymarginally considered, the example approach described herein may takeinto account possible service scenarios and their expected businessvalue. The integration of the service customer refers to the externalfactor intervening with service execution, a notion as it is widely heldin the discipline of service marketing. From a measuring point of view,eligibility for out-tasking or opening a function to servicestakeholders is difficult to represent in figures. The following examplestatements define out-tasking and visibility as binary variables:

Outtasking(F _(i))ε{0,1}

Visibility(F _(i))ε{0,1}

Beyond the assessment of possible stakeholder integration, the number oforganizational units also represents a potentially relevant indicator.Having no organizational unit involved implies full automation. If onlyone organizational unit (and no application systems) is attached, thefunction may be considered a manual task. Semi-automated functions mayhave both an organizational unit and an application systems assigned.The involvement of more than one organizational unit may indicate teamefforts. A function may be assigned either to one organizational unit,to one application system type, or to the combination of both. Multipleorganizational units or application system types may sometimes be vieweda reason to decompose. The following example statements define variablesfor organizational and application resources involved:

OrgOcc(F _(i) ,F ₁)εN: Number of organizational units involved infunction i occurring in process j

AppOcc(F _(i) ,P _(i))εN: Number of application systems involved infunction i occurring in process

Whereas functions attached to multiple application systems types arelikely to be decomposable, team functions (e.g., multiple organizationalunits) may imply collaborative work that is sometimes difficult toseparate further. Such tasks can be exposed as human group services orchecked for (semi-)automation by the use of software reducing the numberof humans involved (e.g., renewal of process institutionalization).Manual activities (e.g., human services) can be further supported byfine granular software services.

In justifying the budgeting and development of an SO-BPS, it oftentimesis desirable to satisfy business goals and objectives. Like any otherinvestment, SO-BPSs are frequently expected to demonstrate their valueto the business on an ongoing basis. In order to bridge the gap betweenbusiness propositions and service realizations and provide traceabilityof services to business drivers, certain example embodiments involvegoal-service modeling (GSM) as a second activity complementing top-downprocess decomposition and bottom-up asset analysis.

Example GSM techniques work well with business process modeling. In someinstances, every process step supports at least one business goal andevery business goal is supported by at least one function. Complementedby the relationship between service capabilities and process functions,this dependency allows for transitively allocating business objectivesto service over functions. The ARIS methodology, for example, includesgoal modeling and proposes goal hierarchies that link a subordinate goalwith several overriding goals and assign goals to functions that provideadequate support. A solid business process analysis project may startwith specifying the objectives of the organization. Because high-levelcorporate goals are usually stated in ways that are too lofty forservice identification, it is advisable to decompose the goals intosub-goals and keep decomposing until that a sub-goal is actionable.Actionable sub-goals are capable of being acted on, e.g., such that onecan identify a function that supports this actionable sub-goal.

Functions linked to business goals would then have a higher probabilityof being prioritized for service realization and funded for subsequentdesign and implementation. This allows using GSM as a scoping mechanismthat reduces the complexity of the SO-BPS problem domain by detecting afunctional area that provides the highest impact on the business side.The following example statements define business objective relevance asan indicator for service eligibility:

BOR(F _(i))ε{1,2,3}

BOR(F_(i)): Business objective relevance of function i

Event-oriented process modeling and event processing implicates aspecific consideration of business events. There are at least twoapproaches of service identification that take business events intoaccount. One can identify data service operations by aggregating dataattributes that are processed at the same time (e.g., triggered by thesame business event). For each set of aggregated data attributes, a dataservice operation is created. In addition, this concept proposes atop-down event-driven method for defining discrete business services.Identifying non-trivial, significant business events includes adequatebusiness responses (e.g., functions triggered by the events). Thoseevent responses define the requirements for the interface design (e.g.,for the service capabilities).

Initiating service identification on an events basis provides anadditional approach on the road towards a possibly complete, adequaterequirements basis for services. Process-oriented service identificationalready took into account how many non-identical events trigger afunction across all business processes. From an event perspective, it isnow analyzed which functions are triggered by non-trivial, significantbusiness events. Therefore, business events are identified and checkedfor responsive functions. Functions related to business events rise inbusiness value and are therefore prioritized in their eligibility.Unlike the other event-oriented value, this does not indicate potentialreusability of a function but its business relevance. It adds to thebusiness relevance driven by business objectives. The example statementsbelow define business event relevance of a function:

BER(F _(i))εN

BER(F): Number of business events function i responds to

Bu sin ess Re levance(F _(i))=BER(F _(i))+BOR(F _(i))

Each indicator elicited may be documented in a service identificationmatrix providing a compound overview on all perspectives of serviceeligibility. The Service Identification and Evaluation Matrix (SIEM) maytake discrete indicator values of the previous analysis and performcalculations, e.g., to transform them into eligibility values acrossdimensions. An additive formula with configuration parameters istherefore proposed in certain example embodiments. The function types ofthe lowest hierarchy level (and not their occurrences in a processcontext) may be evaluated for service eligibility. The rationale behindthis approach is that not a single occurrence in one specific processshould decide about service eligibility but the overall usage of thisfunction in multiple processes. The indicator-based approach takes upthe idea of a service litmus test to underscore the importance ofcriteria that allows the prioritization of service candidates and adocumented justification for the services canceled out in the currentproject scope but relevant in another future scope.

FIG. 1 is an illustrative Service Identification and Evaluation Matrixin accordance with certain embodiments. The rows in FIG. 1 correspond tofunctions, whereas the columns are grouped into process indicators, dataindicators, organizational indicators, and goal and event indicators. Asalluded to above, the values within these categories are additivelycombined to calculate a score indicative of the total serviceeligibility.

The design of the summative eligibility formula depends on factors suchas, for example, the individual project objectives. Before enforcing aformula design, it may be desirable to take the specific SO-BPSenvironment, goals, and other relevant and specific factors intoaccount. If B2B scenarios are important to the SO-BPS project, forexample, the out-tasking and visibility values may be weightedsignificantly higher than in a pure consolidation project that aims toremove redundancies. In this analysis, the example overall serviceeligibility formula set forth below is based on the assumption thatbusiness alignment is the overall objective. This implies that a servicecandidate must be business aligned (e.g., traceable back to a businessgoal). The higher the priority of this business goal, the higher theservice eligibility value.

ServiceEligibility(F _(i))=BusinessRelevance(F _(i))[Reuse(F _(i),t)−DataCoupling(F _(i))+DataCohesion(F _(i))+Outtasking(F_(i))+Visibility(F _(i))−maxOrgOcc(F _(i))−maxAppOcc(F _(i))]

The results of this example formula for each function determine theeligibility of each function to be exposed as a service capability.Having determined a critical value k, one can derive a list of eligibleservice capabilities by filtering out those functions that have a highereligibility value than k.

Now that a list of service eligible functions has been determined,corresponding service capability types are specified. Service capabilitytypes may represent the required service functionality of a service typethat has not yet been implemented or selected. Multiple servicecapability types may constitute a service type that acts as a container.This complies with the type-level modeling approach chosen for businessprocess design. Each service capability type may be complemented withdetailed requirements on possible service implementations.

EXAMPLE

Based on the concept of service indicators described above, anillustration of how they can be used in the domain of corporate learningmanagement processes will now be provided as an example implementation.Of course, it will be appreciated that other service indicators and/orsummative techniques may be used in connection with this exampleimplementation. Furthermore, it will be appreciated that the same ordifferent service indicators and/or summative techniques may be appliedto different implementations.

The case starts with setting up a service-oriented process architecturefor learning management. This endeavor is accomplished in various stepsthat include as a core task the identification of required servicecapabilities with an indicator-based service identification andevaluation matrix (SIEM). FIG. 2 illustrates the example learningmanagement process hierarchy in three levels of detail. Sub-processes ofthe second level are process-oriented subordinates to the top levelphases and may be broken down even further into third levelsub-processes. Shaded elements represent samples that form an end-to-endprocess that is referred to in the remainder of this section ascompetency planning process. As indicated by small assignment icons, thethird hierarchy level is further detailed by event-driven process chainsassigned to the corresponding sub-process elements. Because this also isthe leaf level, they are described and designed in the subsequentsection. The sub-processes are described as follows for the purpose ofthis example:

-   -   Competency Needs Analysis identifies competency requirements        based on strategic business objectives. Mapping business        objectives to business operations, business processes provide a        solid basis for collecting competency needs. Job descriptions        and role definitions may also contribute to the elicitation        process as much as career objectives of individual employees.        Once identified, competency requirements are specified following        predefined structures. To allow for dedicated performance        improvement, competencies are prioritized according to their        impact on business objectives. Other dimensions of competency        prioritization may be training costs, training availability, or        time constraints.    -   Competency Management matches available competencies with        required competencies to identify competency gaps. As a        prerequisite, as-is competencies have been assessed. Knowledge        about competency gaps supports informed decisions on staffing        and role assignment as much as a further definition of        competency objectives both on an individual and on an        organizational level.    -   Competency objectives flow into Curriculum Planning activities,        which seek to overcome competency gaps by demand-driven learning        designs. Pedagogical and communication concepts are aligned with        competency objectives. Existing learning designs are exploited        for competency development (e.g., learning opportunity        exploitation).    -   Learning Unit Production produces learning content for the        planned curriculum or reuses existing ones that match with        competency objectives of the learning design. Assigning learning        content to single elements of the learning design produces a        learning unit being ready for execution.    -   Learning Course Operations provide learning units to the        individual employees facilitated by administrative and technical        support. Learning assessment activities determine the progress        of the learners and help adapt learning courses to individual        needs.    -   Evaluation measures the impact of learning on performance both        on an individual and on an organizational level. The level        determines methods of information retrieval and analysis. On the        one hand, surveys allow for evaluating individual learning        performance. On the other hand, process monitoring delivers        performance data on a process level. Evaluation results indicate        need and type of redesign activities.

An illustrative end-to-end process that runs across all sixsub-processes has been specified and marked as shaded sub-processelements in FIG. 3. It represents a specific use case of learningmanagement that focuses on competency planning and development. Itstarts with a full competency needs analysis eliciting competencyrequirements (e.g., from business processes) (process driven competencyanalysis) and prioritizing them on their impact on process performance(competency simulation). Based on employee competency profiles(competency assessment) the third sub-process merges competency needswith competency availabilities and matches as-is competencies with to-becompetencies of their roles (competency gap analysis). The resultingcompetency gap sets ideal competency objectives that may be refined bycompetency-oriented process simulation. Competency objectives per roleare documented in a competency plan that feeds into curriculum planning.Here, a check is made for reusable learning designs (e.g., pedagogicaltemplates), based on competency annotations (learning design check).They are added to the competency plan and complemented by new learningdesigns (learning design creation). Before becoming deployable, theselearning designs are enriched by learning content that is either alreadyavailable or produced specifically (create learning content).Integrating learning content into learning designs brings about newlearning units that supplement the competency plan.

Following this competency planning process, the competency plan ispassed on to the learning course operation phase, where learning unitsare instantiated per employee to learning courses. After execution oflearning courses, which include assessments, learning performance andprocess performance are evaluated against business objectives.Performance results feed into overall business performance evaluation.Deviations from business and optimization objectives suggest revisitingimprovement measures for process and learning designs.

FIGS. 4A-4D illustrate the sample learning management process fromend-to-end and provides detailed views on two sample leaf level EPCdiagrams. A process context of each process function is specified inassigned function allocation diagrams (FAD). They give information onthe organizational unit performing the function, application systemssupporting the function, and data input and output of the function, aswell as business objectives supported by the function and competenciesinvolved in performing the functions. Person types (organizational unit)and application systems also appear in the EPC diagrams to providedirect information on the current process institutionalization. Thedegree of automation is emphasized by the different resource typesassigned. Manual functions only have organizational units assigned,automated functions have only application systems assigned, andsemi-automated functions have both resource types assigned. Further,data elements are integrated into an overall enterprise resourcemanagement (ERM) data model.

Having mapped out learning management processes for this example, thenext task is to identify service capabilities required by processstructures. Service eligibility values of each process function arecalculated and analyzed across all process models according to theindicators and formula proposed by the example SO-BPS methodologydescribed above.

Resulting service eligibility values roughly present a normaldistribution that allows categorizing four classes of process functions,as shown in FIG. 5. Out of 81 process functions, five are ranked incategory A achieving values of six and better. The process function“determine competency gap” even attains a service eligibility value of11. The set of A functions excel because of their high reusability,out-tasking, and high visibility values. A majority of 63 functionsdeliver values higher than two and lower than six. They are split intotwo categories. Service eligibility of 4 and 5 characterizes Bfunctions. Service eligibility of 3 and 2 characterizes C functions.Those two mid classes exhibit average reusability and varyingvisibility/out-tasking values. A minority of 14 functions measure lessthan 1 service eligibility points and are ranked as D functions. Theirlow values result from low reusability on the one hand and zerovisibility and out-tasking values on the other hand.

The FIG. 5 example analysis suggests some general conclusions linked tothe specific domain of this case study. Reusability values, especiallyoccurrences, appear rather low. The reason is likely to be the limitedscope of the selected end-to-end process in this case study. It isreasonable to assume that the inclusion of neighboring sub-processes ofthe learning management architecture (e.g., HR processes, eventmanagement processes, business strategy processes) would have increasedexpected reusability of process functions in general as the net effecttheory suggests.

Also, data coupling values are rather constant with most processfunctions attaining values of one or two. This is explained by the factthat most input and output of one function is used by at least one otherfunction. And, with most process functions having one input and oneoutput object, this overlap also evens out at 2. However, data cohesionvalues are very low, since most input and output objects are notdirectly related in the underlying data model.

Rather low out-tasking values result from knowledge-intensity of theprocess. An organization's capability to develop employee competenciesconsistent with business objectives is a clear differentiator againstcompetitors. Also, learning management processes often pertain tosensitive employee data. Even more, knowledge-intensive tasks are oftenvery specialized and hard to be conducted by others. For these reasons,organizations are reluctant to out-task these tasks what causes a lowaverage value of out-tasking potentials.

On the other hand, visibility reaches rather high values. This can beunderstood in the context of employee involvement, as well as by thegenerally collaborative character of learning management. The formerinduces notifications of employees about novel learning opportunities,about their competency profile status, about their participation inlearning courses, etc. Collaboration with learning providers requires aconsistent exchange of information which is enabled by notificationservice capabilities.

Organizational indicators of participating organizational units andapplication systems shed light on further service design decisions.Overall high values hint towards further functional decompositioncapacity. Participation of three and more application systems suggest(technical) service composition which may be prepared by an additionalsub-process. Occurrences of two application systems participating in oneprocess function, however, often indicate data exchange. In this case,the technical design may decide about the service roles, e.g., whichsystem provides and which consumes the service. A group of humanparticipants, however, indicates a high degree of collaboration that maynot be resolved by predefined process logic. Instead, this processfunction may be marked as a very likely candidate for a human service.

Once process functions have been analyzed for their service eligibility,they may be categorized into data services, task services and humanservices. Table 1 below provides an overview of the identifiedfunctions, including their ranking and categories. That is, evaluationcategories are provided in parentheses below. Data service capabilitiesare complemented by additional data manipulation functions missing inthe process models so far. They may help facilitate future variations oflearning management processes.

TABLE 1 Process Functions Eligible for Software ServiceCapabilities—Categorized and Evaluated Process Functions Eligible forData Service Capabilities Add competency objectives to competency plan(C) Annotate learning resource with competencies (B) Check if allcompetencies profiles are specified (C) Check if all employeecompetencies are assessed (D) Check if all learning resources arecreated (C) Check if all required learning resources are available (D)Check if competency objects are available for employees (B) Check ifemployees are assigned to roles (B) Create an empty evaluation reportCreate an empty evaluation report (C) Create competency profile Createemployee competency profiles (C) Create empty competency plan (B) Createnew CA-CP (D) Provide business process model Provide learning designProvide learning resource Provide process performance data (B) Retrieveall course participants (C) Retrieve business process model Retrievecompetency plan Retrieve learning design Retrieve learning resourceRetrieve performance data Retrieve process performance data Storeperformance results (B) Transmit survey results (B) Update competencyprofile Process Functions Eligible for Task Service Capabilities Assignemployee to roles (A) Automated competency profiling (B) Carry outsimulation (A) Create Balanced Scorecard (C) Create DuPont Model (C)Create HCM Scorecard (C) Determine competency gap (A) Inform learnerabout learning process (D) Instantiate learning process (B) PublishPerformance Results and Goals (C) Request execution of learning units(B) Search for learning design for competency gaps (C) Search suitablelearning design (C) Select as-is competencies for competency profiles(A) Send invitations (B)

Certain example embodiments may be thought of as including the technicalstructure shown in FIG. 6. In other words, certain example embodimentsoperate in connection with a BPM system by first examining businessprocess analysis intelligence (from design time) and process performanceintelligence (from run-time). Metadata attributes for each model objectare updated so as to include indicators corresponding to design timeand/or run time gathered intelligence. Service candidate analysis isperformed using the indicators stored with the metadata attributes.Service request reports can then be generated.

It is noted that a repository-based modeling tool (such as the ARISplatform) may be provided to allow for analyzing dependencies betweenmodeling artifacts across process models in certain example embodiments.Similarly, process monitoring software systems that allow for processinstance monitoring and performance management (e.g., ARIS PPM) may beprovided in certain example embodiments.

As some variables are calculated based on the analysis of the overallmodel network, macros or reports may be scripted to provide desireddesign time data. For example, a script may feed the variable Occ( ) ofa function with the number of occurrences of this function across allprocess models. Thus, business process analysis intelligence may beprovided.

As some variables rely on run-time process data, an interface to aprocess monitoring tool (such as ARIS PPM) may be developed. It then mayfeed, for example, the number of invocations of a function i over thecourse of time t into the variable Invoc( ) of an EPC function. Thus,process performance analysis intelligence may be provided.

Variables involved in calculating service indicators (e.g., as describedabove) may be maintained in the metadata attribute set of each modelingartifact. Therefore, they may be maintained manually or automaticallyfed by intelligence tooling. In certain example embodiments, variableslike outtasking( ) or visibility( ) may be maintained manually, whileothers may be retrieved from run-time data or the analysis of the modelnetwork. Thus, metadata attributes may be provided. For instance, FIG. 7is an example screenshot showing how gathered service indicators may bemaintained in metadata attributes in accordance with certain exampleembodiments. In FIG. 7, metadata attributes for an illustrative“initiate offer” service are maintained and include the exampleindicators identified above.

The overall eligibility algorithm may be implemented as a script thatruns on a set of EPC functions and takes their variables as inputs. Itmay calculate individual service eligibility values of each function andranks them accordingly. This calculation may be done on the basis of theoverall service eligibility formula with weighted values. The weightsmay depend on, for example, the objectives to be reached with theresulting service-oriented business process systems. Depending on theoverall service eligibility value, a process function may qualify as asustainable service candidate and accordingly may be forwarded toservice development in the next step.

To request the development of the top level service candidates, a reportmay gather all information modeled in the context of the correspondingEPC function and provide them as a requirements specification document.For instance, FIG. 8 is an example screenshot demonstrating how a newservice request may be initiated in accordance with certain exampleembodiments.

FIG. 9 is a more detailed diagram illustrating the technical approach ofcertain example embodiments at both design time and at run time. Asshown in FIG. 9, a process executes on an Enterprise Service Bus (ESB)at run time. However, at design time, a business process is defined. TheFIG. 9 example includes three processes, which each include variousfunctions and services. Business process analysis may be performed onthe defined processes, e.g., at design time. Similarly, businessperformance analysis may be performed on the defined processes, e.g., atrun time. Indicators may be gathered to generate an STEM, which may bestored together with metadata attributes of a selected function,service, or other structure from within one or more of the definedprocesses. A formula may be applied to the indicators to create a totalservice eligibility figure, e.g., as a part of service candidateanalysis. This calculation may help to respond to service requests,e.g., by finding a matching candidate service, which may then beimplemented or executed by the process on the ESN at run time.

It will be appreciated that as used herein, the terms system, subsystem,service, programmed logic circuitry, and the like may be implemented asany suitable combination of software, hardware, firmware, and/or thelike. It also will be appreciated that the storage locations herein maybe any suitable combination of disk drive devices, memory locations,solid state drives, CD-ROMs, DVDs, tape backups, storage area network(SAN) systems, and/or any other appropriate tangible computer readablestorage medium. It also will be appreciated that the techniquesdescribed herein may be accomplished by having a processor executeinstructions that may be tangibly stored on a computer readable storagemedium.

While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the invention is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims.

What is claimed is:
 1. A method of analyzing functions of a businessprocess model for possible exposure as service capabilities in aservice-oriented business process system, the method comprising:receiving a business process model defined by a plurality of objects,each said object having metadata attributes associated therewith;obtaining business process analysis intelligence at design time for eachsaid object; obtaining process performance intelligence at run time foreach said object; storing indicators corresponding to the design timeand run time gathered intelligence together with the metadata attributesfor the corresponding object; applying, via at least one processor ofthe service-oriented business process system, an overall servicecandidate algorithm to the stored indicators to arrive at a totalservice eligibility value for each process function in the model; andexposing a function as a service capability if the total serviceeligibility value for the function exceeds a predetermined thresholdvalue, wherein the indicators include process indicators, dataindicators, organizational indicators, and goal and event indicators,and wherein each total service eligibility value is a weightedcombination of the associated indicators.
 2. The method of claim 1,further comprising responding to a request for a service candidate byrecommending at least one process function having a sufficiently hightotal service eligibility value.
 3. The method of claim 1, wherein theweights correspond to one or more objectives to be reached with theresulting service-oriented business process system.
 4. The method ofclaim 1, wherein the indicators include at least one reusabilityindicator for functions in the model, at least one data couplingindicator for functions in the model, at least one data cohesionindicator for functions in the model, at least one stakeholderintegration indicator for functions in the model, at least oneorganizational involvement indicator for functions in the model, atleast one goal-oriented indicator for service eligibility, and/or atleast one event-oriented indicator for service relevance.
 5. The methodof claim 1, wherein the weights correspond to one or more objectives tobe reached with the resulting service-oriented business process system6. The method of claim 1, further comprising: gathering the design timeintelligence via scripted macros or reports; and gathering the run timeintelligence via an interface to a process monitoring tool.
 7. Themethod of claim 1, further comprising ranking the total serviceeligibility values for the process functions.
 8. The method of claim 7,further comprising organizing the ranked total service eligibilityvalues into groups based on the rankings.
 9. The method of claim 8,wherein the groups are formed so as to approximate a normaldistribution.
 10. The method of claim 8, further comprising displayingthe groups to a user of the service-oriented business process system.11. A method of defining or refining a business process model, themethod comprising: graphically displaying, on a display of a computersystem, a representation of at least a portion of the business processmodel, the portion including a plurality of objects; enabling a user toselect an object of the model via a user interface; in response to auser request received via the user interface, graphically displaying, onthe display of the computer system, metadata attributes of the selectedobject, wherein indicators corresponding to gathered business processanalysis intelligence and/or gathered process performance intelligenceare displayed together with the metadata attributes in a matrix format;calculating, via at least one processor, a total service eligibilityvalue for each process function in the model based on a weightedsummation of the indicators, wherein the indicators correspond to thebusiness process analysis intelligence are gathered at design time viascripted macros or reports and the indicators corresponding to theindicators corresponding to the process performance intelligence aregathered at run time via an interface to a process monitoring tool;receiving a request for a service from the user; and displaying at leastone service candidate as a result of the request.
 12. The method ofclaim 11, wherein a plurality of service candidates are displayed. 13.The method of claim 12, wherein the service candidates are ordered basedon their respective total service eligibility values.
 14. The method ofclaim 11, wherein each said service candidate is displayed only if itexceeds a predetermined threshold value.
 15. The method of claim 11,wherein exactly one service candidate is displayed, the servicecandidate corresponding to the function having the highest total serviceeligibility value.
 16. A non-transitory computer readable storage mediumincluding instructions that, when executed by a processor of a computersystem, perform the method of claim
 1. 17. A non-transitory computerreadable storage medium including instructions that, when executed by aprocessor of a computer system, perform the method of claim
 11. 18. Aservice-oriented business process system for analyzing functions of abusiness process model for possible exposure as service capabilities,comprising: a non-transitory computer readable storage medium includinga representation of the business process model, the business processmodel being defined by a plurality of objects, each said object havingmetadata attributes associated therewith, the metadata attributes alsobeing stored in the computer readable storage medium; a firstcomputer-executable intelligence gathering module configured to obtainbusiness process analysis intelligence at design time for each saidobject; a second computer-executable intelligence gathering moduleconfigured to obtain process performance intelligence at run time foreach said object; a computer-executable analysis module configured to(a) receive indicators corresponding to the design time and run timegathered intelligence, and (b) apply a service candidate algorithm onsome or all of the indicators to arrive at a total service eligibilityvalue for each process function in the model; and a report generatorconfigured to recommend at least one service candidate in response torequest for a function, the recommendation being based on total serviceeligibility values associated with the functions; wherein the modulesare executable via at least one processor of the system, wherein theindicators include process indicators, data indicators, organizationalindicators, and goal and event indicators, and wherein the total serviceeligibility value is a weighted combination of the indicators.
 19. Thesystem of claim 18, wherein the weights correspond to one or moreuser-specified objectives to be reached with the resultingservice-oriented business process system.
 20. The system of claim 18,wherein the at least one processor is configured to expose a function asa service capability if the total service eligibility value for thefunction exceeds a predetermined threshold value.